The Abstract Class Pattern

CLASS Class Behavioral Intent Define the interface for a hierarchy of classes while deferring the implementation to subclasses. Abstract Class lets subclasses redefine the implementation of an interface while preserving the polymorphism of those classes. Also Known As Liskov Substitution Principle [LW93], Design by Contract [Meyer91], Base Class [Auer95] , Template Class [Woolf97] Motivation Consider the need to perform simple arithmetic. Every application needs to use simple numbers like integers and floats and to perform simple arithmetic such as addition, subtraction, multiplication, and division. One obvious way to perform this simple math is to let the CPU do it. Any modern CPU has built in commands to perform simple arithmetic with integers and floats. This is the most efficient way to perform such calculations. The problem is that not all numerical quantities can be adequately represented as the CPU’s integers and floats. Integers have a limited range. Floats have limited precision and loose precision converting between decimal and binary. The number framework in a robust object-oriented system should take advantage of the CPU’s efficiency whenever possible. However, to make the system more robust, the framework should overcome the CPU’s limitations whenever possible. It should be able to represent a virtually limitless range of numbers, both really huge numbers and really tiny ones. It should be able to represent a decimal number with complete precision, at least to a specified number of decimal places. It should be able to perform simple arithmetic without any loss of precision. It could even compute complex equations by simplifying them first. A robust number framework employs various classes to meet these goals: Integer and Float for CPU numbers, LargePositiveInteger and LargeNegativeInteger for huge integer values, FixedPoint for complete precision, Fraction for division without round off, and so on. This way, the framework performs as much computation as possible using the CPU, but also uses other classes to represent numbers that that the CPU cannot. The diagram below shows the classes for this framework. The Abstract Class Pattern Bobby Woolf 07/17/97 10:13 2 of 8 The problem with all of these number classes is that the rest of the system does not want to be aware of them. To the rest of the system, there are just number objects and they know how to perform arithmetic. When code somewhere in the system has a statement like “x + y,” it does not care whether x is a Float or y is a Fraction. The code just knows that x and y are numbers and that numbers know how to perform addition. The implication is that since some numbers know how to perform addition, all numbers must be able to. Thus the number framework requires more than just these various number classes. It also needs to clearly show which classes are part of the framework. It needs to require that all classes in the framework be able to perform a certain minimal amount of functionality, such as addition. And the framework needs to provide all of this number functionality in a polymorphic way to hide the complexity of the various subclasses from the rest of the system. The framework will accomplish all of this by using a generalized superclass called Number. A Number represents any kind of number, be it an integer, float, or whatever. It defines the minimal functionality that any number must provide, such as addition. It does not define a number’s structure, nor does it define the implementation of the functionality. Those details are deferred to subclasses like Integer, Float, and so on. Applying Number as a superclass, and implementing Integer in a similar manner, leads to the framework of classes shown below. Object + * / LargePositiveInteger + * / Integer